Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000197_owner-urn-ietf _Mon Nov 25 12:06:02 1996.msg

Internet Message Format | 1997-02-19 | 25KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA24916 for urn-ietf-out; Mon, 25 Nov 1996 12:06:02 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA24907 for <[e-mail]>; Mon, 25 Nov 1996 12:05:47 -0500
Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA06863  (mail destined for [e-mail]); Mon, 25 Nov 96 12:05:27 -0500
Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id MAA17730; Mon, 25 Nov 1996 12:05:22 -0500
Date: Mon, 25 Nov 1996 12:05:22 -0500
Message-Id: <[e-mail]>
From: "Karen R. Sollins" <[e-mail]>
To: [e-mail]
Subject: [URN] URN resolution requirements and framework
Sender: [e-mail]
Precedence: bulk
Reply-To: "Karen R. Sollins" <[e-mail]>
Errors-To: [e-mail]

Hi!

Attached is the first draft of a proposed document on requirements and
a framework for URN resolution.  It is based on the internet drafts
presented at the URN BOF in Montreal separately on requirements
(without the discussion of various schemes) and the framework document
by Leslie, Patrik, and Renato.  I have added an additional preliminary
section on assumptions, which seems important in light of some of the
discussions on this list.  I've also tried to enhance the
requirements, again based on discussions and broaden the framework a
little, to make it less specific to the NAPTR proposal, in order to
extend its utility.

We will talk about it in San Jose, but in the meantime comments and
discussion (no rotten eggs or tomatoes, please:-) are welcome.

            Karen

PS: To the Americans on the list, have a nice Thanksgiving!
______________________________

Internet Draft                                          Karen R. Sollins
draft-ietf-urn-req-frame-00.txt                                  MIT/LCS
Expires May 26, 1997                                   November 26, 1996

    Requirements and a Framework for URN Resolution Systems


Status of this draft
     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     ``work in progress.''

     To learn the current status of any Internet-Draft, please check
     the ``1id-abstracts.txt'' listing contained in the Internet-
     Drafts Shadow Directories on ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


Abstract:

This document addresses the issues of the discovery of local URN
resolution services that in turn will directly translate URNs into
URLs and URCs.  The document falls into three major parts, the
assumptions underlying the work, the requirements in order to be a
viable URN-resolution-service discovery service or UDS, and a
framework for designing UDSs.  The requirements fall into three major
areas: evolvability, usability, and security and privacy.  A UDS that
is compliant with the framework will not necessarily be compliant with
the requirements.  Compliance with the requirements will need to be
validated separately.

1. Introduction

The purpose of this document is to lay out the engineering criteria for
what we will call here a URN-resolution-service discovery service (UDS).
__________

Acknowledgments

Foremost acknowledgment for this document goes to Lewis Girod, as my
co-author on a previous URN requirements document and for his insightful
comments on this version of the document.  In addition, I recognize the
contributors to a previous URN framework document, the "Knoxville"
group.  There are too many of you to acknowledge here individually, but
thank you.  Finally, I must thank the contributors to the URN working
group mailing list ([e-mail]), for their animated discussions
on these and related topics.

URN Resolution Requirements                                      Page  1

This is a component of the realization of an information infrastructure.
In the case of this work, that infrastructure is to be available, "in
the Internet" or globally, and hence the solutions to the problems we
are addressing must globally scalable.  In this work, we are focussing
specifically on naming of resources and resolution of those names to the
exclusion of other problems such as typing, resource access and
availability, security of the resources, etc.  Those are all important
problems, but not part of this effort.

The Uniform Resource Identifier Working Group defined a naming
architecture, as demonstrated in a series of three RFCs 1736[RFC1736],
1737{RFC1737}, and 1738[RFC1738].  Although several further documents
are needed to complete the description of that architecture, it
incorporates three core functions often associated with "naming":
identification, location, and mnemonics or semantics.  Names may provide
the ability to distinguish one resource from another, by distinguishing
their "names".  Names may help to provide access to a resource by
including "location" information.  Lastly, names may have other semantic
or mnemonic information that either helps human users remember or figure
out the names, or include other semantic information about the resource
being named.  The URI working group concluded that there was need for
persistent, globally unique identifiers, distinct from location or other
semantic information; these "names" provide identity, in that if two of
them are "the same" (under some simple rule of canonicalization), they
identify the same resource.  Furthermore, the group decided that these
"names" were generally to be for machine, rather than human consumption.
One can imagine a variety human-friendly naming (HFN) schemes supporting
different suites of applications and user communities.  These will need
to provide mappings to URNs in tighter or looser couplings, depending on
the namespace.  It is these that will be mnemonic, content-full, and
perhaps mutable, to track changes in use and semantics.  They may
provide nicknaming and other aliasing, relative or short names, context
sensitive names, descriptive names, etc.  The URI naming architecture as
described in the introductions to RFCs 1736 and 1737 lays out three
sorts of components to the naming architecture: identifiers called
Uniform Resource Names (URNs), locators called Uniform Resource Locators
(URLs) and semantic meta-information called Uniform Resource
Characteristics (URCs).  This document focusses on part of the problem
of the translation from URN to URL and/or URC.

Within the URI community there has been a concept used frequently that
for lack of a better term we will call a _hint_.  A hint is something
that helps in the resolution of a URN.  Examples of hints are: 1) the
name of a resolution service that may further resolve the URN, 2) the
address of such a service, 3) a location at which the resource was
previously found.  The defining feature of hints is that they are only
hints; they may be out of date, temporarily invalid, or only applicable
within a specific locality.  They do not provide a guarantee of access,
but they probably will help in the resolution process.  Wemust assume
that most resolutions of URNs will be provided by the use of locally
stored hints, because maintaining a database of globally available,
completely up-to-date location information is infeasible for performance
reasons.  There are a number of circumstances in which one can imagine
that hints become invalid, either because a resource has moved or
because a different URN resolution service has taken over the

URN Resolution Requirements                                      Page  2

responsibility for resolution of the URN.  Hints may be found in a
variety of places.  It is generally assumed that a well engineered
system will maintain a set of hints for each URN at each location where
that URN is found.  In addition, for those situations in which those
hints found locally fail, a well-engineered system will provide a
fall-back mechanism for discovering further hints.  It is this fall-back
mechanism, a UDS, that is being addressed in this document.  As with all
hints, there can never be a guarantee that access to a resource will be
available to all clients, even if the resource is accessible to some.
However, a UDS is expected to work with reasonably high reliability,
and, hence, may result in increased response time.  The remainder of
this document falls into three sections.  The first identifies several
sets of assumptions underlying this work.  The next lays out the
requirements for a URN-resolution-service discovery service.  This
section is probably the most critical of the document, because it is
this that provides the metric for whether or not a proposed scheme for a
UDS is adequate or not.  For the reader short on time, each of the three
major subsections of the requirements section concludes with a summary
list of the requirements identified in that section.  The final section
of the document lays out a framework for such UDSs.  The purpose of this
last section is to bound the search space for UDS schemes.  One must be
careful not to assume that because a UDS scheme fits within the
framework that it necessarily meets the requirements.  As will be
discussed further in this last section, designing within the framework
does not guarantee compliance, so compliance evaluation must also be
part of the process of evaluation of a scheme.

2. Assumptions

Based on previous internet drafts and discussion in both the URN BOFs
and on the URN WG mailing list, three major areas of assumptions are
apparent: longevity, delegation, and independence.  Each will be
discussed separately.

The URN requirements state that a URN is to be a "persistent
identifier".  It is probably the case that nothing will last forever,
but in the time frame of resources, users of those resources, and the
systems to support the resources, the identifier should be considered to
be persistent or have a longer lifetime than those other entities.
There are two assumptions that are implied by longevity of URNs:
mobility and evolution.  "Mobility" assumes that.  everything will move
over the life of a URN.  For example, resources will move from one
machine to another, because individual machines have a much shorter
lifetime than resources, generally measured in a number of years less
than a decade.  Owners of resources may move and wish their resources to
follow them.  The services themselves will move.  "Evolutions" assumes
that the supporting infrastructure will evolve.  This may take the form
of entirely new transport protocols or new versions of existing
protocols.  Furthermore, services such as storage services may evolve;
it is even possible that within a human lifetime the Unix file system
model may no longer be in use!  Clearly there will be evolution of and
improvement in supporting authentication and security mechanisms.  These
are only examples.  In general, we must assume that almost any piece of
the supporting infrastructure of URN resolution will evolve.  In order
to deal with both the mobility and evolution assumptions that derive

URN Resolution Requirements                                      Page  3

from the assumption of longevity, we must assume that users and their
applications can remain independent of these mutating details of the
supporting infrastructure.

The second and third assumptions are two forms of modularity, delegation
and isolation.  The delegation assumption is that an entity may
partition and pass off some of its authority or responsibility.  One of
those responsibilities is for assigning URNs; practically speaking,
there cannot be only a single authority for assigning URNs.  We expect
that there will be a multi-tiered naming authority delegation.
Furthermore, it is difficult to imagine a non-partitioned and delegated
global UDS, meaning that hint discovery and resolution will be
partitioned and delegated.  In some UDS schemes, the delegation of
naming authority will form a basis for delegating the management and
dispensing of location information.

The third assumption is independence or isolation of one authority from
another and, at least to some extent from its parent.  Underlying much
of the thinking and discussion in the URI and URN working groups has
been the assumption that when a component delegates authority to another
component, the delegatee can operate in that domain independently of its
peers and within bounds specified by the delegation, independently of
the delegator.  This isolation is critically important in order to allow
for independence of policy and mechanism.

There are a number of more specific assumptions that fall under this
rubric of isolation.  First, we assume that the publisher of a resource
can choose resolution services, independently of choices made by others.
At any given time, the owner of a namespace may choose a particular URN
resolution service for that delegated namespace.  Such a URN resolution
service may be outside the UDS service model, and just identified or
located by the UDS service.  Second, it must be possible to make a
choice among UDS services, perhaps based on different underlying
internal architectures.  The reason that this is an assumption is that
there must be an evolutionary path through a sequence of core UDS
services.  Although at any given time there is likely to be only one or
a small set of such services, the number is likely to increase during a
transition period from one architecture to another.  Thus, it must be
assumed that clients can make a choice among a probably very small set
of UDSs.  Third, there must be independence in the choice about levels
and models of security and authenticity required.  This choice may be
made by the owner of a naming subspace, in controlling who can modify
hints in that subspace.  A naming authority may delegate this choice to
the owners of the resources named by the names it has assigned.  There
may be limitations on this freedom of choice in order to allow other
participants to have the level of security and authenticity they
require, for example, in order to maintain the integrity of the UDS
infrastructure as a whole.  Fourth, there is an assumption of
independence of choice of the rule of canonicalization of URNs within a
namespace, limited by any restrictions or constraints that may have been
set by its parent namespace.  This is a choice held by naming
authorities over their own subnamespaces.  Rules for canonicalization
will be discussed further in the framework section below.  Thus, there
are assumptions of independence and isolation to allow for delegated,
independent authority in a variety of domains.

URN Resolution Requirements                                      Page  4

The modularity assumptions of delegation and isolation imply
independence of decision and implementation, leading to a
decentralization that provides a certain degree of safety from denial of
service.  Based on these these assumptions in conjunction with that of
longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737,
we can now turn to the requirements for a URN services delegation
service.

3. Requirements

The requirements applying to a URN-resolution-service discovery service
or UDS center around three important design goals: evolvability,
usability, and security and privacy.  At its core the function of a UDS
is to provide hints for accessing a resource given a URN for it.  These
hints may range in applicability from local to global, and from
short-lived to long-lived.  They also may vary in their degree of
verifiable authenticity.  While it may be neither feasible nor necessary
that initial implementations support every requirement, every
implementation must support evolution to systems that do support every
requirement.

It is also important to note that there are other requirements, not
applicable specifically to a UDS that must also be met.  A whole URN
system will consist of namespaces, the resolution information for them,
and the mapping from names in the namespaces to resolution information
(or hints).  URN schemes must meet the requirements of RFC 1737.
Resolution information, to the extent it is expressed as URLs must meet
the requirements of RFC 1736.  But this does not tell the whole story.
Although the URN working group will identify several acceptable
namespaces and the rules binding them, such as how delegation occurs,
how it is expressed in the names, how and to what extent binding to hint
information will be constrained by the namespace, in the long run a
document will be needed to guide the evaluation criteria for acceptance
of new namespaces.  These are not included in the list of requirements
below because they are not requirements for a UDS, but rather for naming
schemes themselves.

3.1 Evolution

One of the lessons of the Internet that we must incorporate into the
development of mechanisms for resolving URNs is that we must be prepared
for change.  Such changes may happen slowly enough to be considered
evolutionary modifications of existing services or dramatically enough
to be considered revolutionary.  They may permeate the Internet universe
bit by bit, living side by side with earlier services or they may take
the Internet by storm, causing an apparent complete transformation over
a short period of time.  There are several directions in which we can
predict the need for evolution, even at this time, prior to the
deployment of any such service.  At the very least, the community and
the mechanisms proposed should be prepared for these.

First, we expect there to be additions and changes to the mechanisms.
The community already understands that there must be a capacity for new
URN schemes.  A URN scheme will define a set of URNs that meet the URN
requirements[RFC1737], but may have further constraints on the internal

URN Resolution Requirements                                      Page  5

structure of the URN.  The requirements document would allow for an
overall plan in which URN schemes are free to specify parts of the URN
that are left opaque in the larger picture.  In fact, a URN scheme may
choose to make public the algorithms for any such "opaque" part of the
URN.  For example, although it may be unnecessary to know the structure
of an ISBN, the algorithm for understanding the structure of an ISBN has
been made public.  Other schemes may either choose not to make their
algorithms public, or choose a scheme in which knowledge of the scheme
does not provide any significant semantics to the user.  In any case, we
must be prepared for a growing number of URN schemes.

Often in conjunction with a new URN scheme, but possibly independently
of any particular URN scheme, new resolution services may evolve.  For
example, one can imagine a specialized resolution service based on the
particular structure of ISBNs that improves the efficiency of finding
documents given their ISBNs.  Alternatively, one can also imagine a
general purpose resolution service that trades performance for
generality; although it exhibits only average performance resolving
ISBNs, it makes up for this weakness by understanding all existing URN
schemes, so that its clients can use the same service to resolve URNs
regardless of naming scheme.  In this context, there will always be room
for improvement of services, through improved performance, better
adaptability to new URN schemes, or lower cost.  In any case, new models
for URN resolution will evolve and we must be prepared to allow for
their participation in the overall resolution of URNs.

If we begin with one overall plan for URN resolution, into which the
enhancements described above may fit, we must also be prepared for an
evolution in the authentication schemes that will be considered either
useful or necessary in the future.  There is no single globally accepted
authentication scheme, and there may never be one.  Even if one does
exist at some point in time, there will always be threats to it, and so
we must always be prepared to move on to newer and better schemes, as
the old ones become too easily spoofed or guessed.

Lastly, in terms of mechanism, although we may develop and deploy a
single UDS scheme initially, we must be prepared for that top level
model to evolve.  Thus, if the UDS model supports an apparently
centralized (from a policy standpoint) scheme for inserting and
modifying authoritative information, over time we must be prepared to
evolve to a different model, perhaps one that has a more distributed
model of authority and authenticity.  If the model has no core but
rather a cascaded partial discovery of information, we may find that
this becomes unmanageable with an increase in scaling.  Whatever the
core of the model, we must be prepared for it to evolve with changes in
scaling, performance, and policy constraints such as security and cost.

Second, in addition to the evolution of resolution mechanisms, we expect
that the community will follow an evolutionary path towards the
separation of semantics from identification.  The URN requirements
document suggested this path as well, and there has been general
agreement in much of the community that such a separation is desirable.
This is a problem that the public at large has generally not understood.
Today we see the problem most clearly with the use of URLs for
identification.  When a web page moves, its URL becomes invalid.

URN Resolution Requirements                                      Page  6

Suppose such a URL is embedded in some page, stored in long term
storage.  There are three possible outcomes to this scenario.  One
possibility is that the client is left high and dry with some message
saying that the page cannot be found.  Alternatively, a "forwarding
pointer" may be left behind, in the form of an explicit page requesting
the client to click on a new URL.  Although this will allow the client
to find the intended page, the broken link cannot be fixed because the
URL is embedded in a file outside of the client's control.  A third
alternative is that the target server supplies an HTTP redirect so that
the new page is provided for the client automatically.  In this case,
the client may not even realize that the URL is no longer correct.  The
real problem with both of these latter two situations is that they only
work as long as the forwarding pointer can be found at the old URL.
Semantics, in this case location information, was embedded in the
identifier, and the resolution system was designed to depend on the
semantics being correct.  There are few cases in which we can expect
semantics of any sort to remain valid for a long time, but in many cases
references need to have long lifespans.  Most documents are only useful
while their references still function.

We expect the evolution to separation of semantics from identification
to move along at least three paths.  The first will be to develop
temporary aliases to capture the semantics currently embedded in
identifiers.  This will require additional translation, but it will
allow for the development of semantics-free URNs.  Second, we expect
locally shared or private aliases to arise, again supported by a
translation mechanism and allowing for the long-term storage of global,
semantics-free URNs.  Such an aliasing scheme may be used to permit
local aliases for named resources as well as to present these aliases to
users in lieu of the URNs themselves.  Lastly, we expect there may be a
development of global aliases.  These will be more user friendly "names"
that would be shared on a much larger scale, and might be defined in
some global registry.  This may include trademarked names as well as
names in extremely common use.  As with the other alias systems, a
facility for translation is needed.  However, in this case, since the
system of aliases is of global scope, the translation facility will be
very slow if each time an alias is translated it needs to query a
centralized or even reasonably distributed global registry.  In order to
achieve acceptable speeds, the translation facility w